Bus bridge verification system including device independent bus monitors

ABSTRACT

A transaction checking system and method to verify bus bridge designs in multi-master bus systems. A state machine model is created for each bus in the system. An initiator cycle list and a target cycle list store corresponding bus cycle state machine objects and transition their states according to bus signals. The bus cycle state machines provide a means of persistent storage for other verification tasks. A bus bridge model may store a copy of each configuration register for the bus bridge, thereby monitoring current state of the bus bridge. False failures due to data merging, data collapsing and address remapping are avoided. A cache model and a cycle-based messaging system provide verification of proper cache master operation. Cache coherency errors may also be detected. A statistics keeping object may be created to monitor and store all pertinent performance information for the bus bridge. The transaction checking system may monitor the state of the bus bridge in a device independent manner and with tighter verification. The cycle-based approach to verification of internal states of a bus bridge results in a sound resolution of bus cycles with a better predictability of possible failures. Bus monitors may be employed along with the bus bridge model object to determine the values of the bus bridge configuration registers. This allows timing and other protocol related functionality of a system bus attached to the bus bridge to be verified without restricting the bus monitor to a specific bus bridge design (e.g., without requiring the bus monitors to maintain the net list names for the various configuration registers identified by the hardware description language representation of the bus bridge). Additionally, future bus bridge designs can also be tested in a device independent manner.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to devices and methods for testing thefunctionality of components of a computer system and, more particularly,to object-oriented design methodologies for testing the functionality ofbus bridge implementations for use with multi-master computer systems.

2. Description of the Related Art

Reliability and efficiency of any computer system depend in part uponthe system complexity as well as upon the measures taken to minimize orprevent occurrences of faulty operations. Various modern-day mechanisms,including parallel processing, high-speed microprocessors, RISC (ReducedInstruction Set Computer) architectures and on-board hardwareredundancies allow faster system performance and throughput whileincreasing system reliability. Particularly in relatively complex, highperformance systems, it is important to provide means for testing theproper functionality of the system and to provide fault corrections bothupon the design and manufacture of the various system components, andduring system operation.

Monitoring and verifying the functionality of a particular design of acomputer system component through software means has undoubtedly provento be a reasonable alternative to manual verification methodologies andto purely hardware test systems. The use of software for systemverification is not, however, entirely without its attendant costs. Thetime required to perform various tests may be lengthy. Furthermore, andperhaps of greater significance, is the fact that the overall accuracyor coverage of the tests may be limited, thus leading to indications offalse failures or to undetected defects.

Corrupted bus cycles in a system can be a major source of loss ofreliability or efficiency. It is not uncommon for bus cycles initiatedby various bus masters to not reach their desired destinations, or tootherwise be corrupted. This can result from various factors, such asimproper hardware design, faults in bus lines, physical or functionaldefects in chip or board fabrications, and faulty execution in systemsoftware routines. A key component in many computer systems whichmanages bus cycles is a bus bridge. Verification systems have thus beendeveloped to verify the design of a bus bridge, either upon its initialdesign in a hardware description language such as Verilog or followingactual hardware implementation.

Historically, verification systems for bus bridge designs have proveninadequate to preserve the right data and right address for every buscycle in a system involving multiple transactions. One prior art methodfor testing the functionality of a bus bridge employs reference countsassociated with each address being written to memory. The CPU decrementsthe count upon completion of the write operation. Although every addresstransaction is given its individual count, this method may fail topreserve address counts in bus bridge implementations that employ memoryremapping.

False failures may also be caused by byte merging, i.e. merging oftransactions to adjacent or contiguous memory addresses. In this scheme,for example, four cycles into the bus bridge may only create only onecycle out. This may result in the bus bridge erroneously incrementing inmultiple counts without decrementing consistent with the mergedtransactions, thus leading to false indications of error.

Byte collapsing is another source of error in bus transactionverification schemes. In this approach, more than one write cycle to thesame memory address may result in only the most recent data beingpreserved. In other words, the earlier data to the particular addressmay be overwritten by a later cycle. Here, as in byte merging, the busbridge testing methodology may fail to preserve the correct addresscount.

Yet another source of error in previous bus transaction verificationschemes is an occurrence of an aborted bus transaction. When cycles toaddresses are aborted without being completed, failures occur if thesystem does not properly track and account for the aborted cycles.

Most transaction testing methodologies for bus bridges treat computersystems as address-based rather than cycle-based. Typical approaches toaddress and data verification do not take into account the internalstates of a machine, nor any other internal states associated with amemory or other system cycles. Critical cycle oriented information maynot be considered, causing inadequate verification. When critical buscycle information is discarded, resolution of later arising cycleconflicts may not be completely sound.

Furthermore, a bus bridge verification requires insuring that each busattached to the bridge operates with a proper timing and protocol. Thisverification is typically accomplished using bus monitors. Bus monitorsare modules that monitor the signals on a given bus and flag improperoperation. Bus monitors are typically constructed in the same hardwaredesign language as the bus bridge being simulated. Also, bus monitorsmay typically perform their verification tasks during the simulation.

In some cases, it is necessary for a bus monitor to be aware of internalbus bridge configuration register values. For example, a DRAM memory busmonitor should verify proper RAS and CAS pulse width values and DRAMrefresh intervals. The values for these timing intervals are set usingconfiguration registers in the bus bridge. Hence, in order to verifythat the bus bridge operation is proper with respect to theseconfigurable timing intervals, the bus monitor directly accesses theconfiguration register values using the actual net name of theconfiguration register in the actual bus bridge design.

This bus monitor dependence on the actual net name of a configurationregister has one major disadvantage: the bus monitor is not portableacross any designs where the net names are varied. A conversion of thenet list that does not preserve net names--as for example, a conversionof an RTL (Register Transfer Logic) net list to a gate net list used forcircuit layout--will also render the bus monitor inoperable.

Therefore, a bus bridge testing methodology and mechanism are needed tomonitor the states of a bus bridge in a computer system to therebydetermine proper functionality. Knowledge of the bus bridge states willallow better determination of failures. It is also desirable to have averification system that monitors and records bus bridge performance,and verifies correct behavior of a bus bridge cache master.

Finally, it is further desirable to have a bus bridge verificationmethodology where timing and other functionality of a system busattached to the bus bridge can be verified in a manner independent ofthe bus bridge's hardware description language representation.Additionally, a bus bridge verification system is desirable that allowsbus monitors to be portable across various bus bridge designs and theirrevisions.

SUMMARY OF THE INVENTION

The problems outlined above are in large part solved by a methodologyand organizational structure for a bus bridge design verification systemin which bus cycles are treated as individual persistent objects.Principles of object oriented design have been utilized to implement thesystem and methodology of the present invention.

A state machine model is created for each bus in the system. Each busmodel (or bus object) is passed various stimulus generated on real orsimulated system buses under test. As a bus object receives stimuluscorresponding to new bus cycles, the bus object is responsible forinstantiating corresponding bus cycle state machine objects and storingor identifying them in at least one of a plurality of bus cycle lists.

In one embodiment, there are three dynamically allocated lists forstoring bus cycle state machine objects in the system. The first twolists hold cycles initiated by bus masters and cycles sent to bustargets, and are called the initiator cycle list and the target cyclelist, respectively. The third list is a special purpose list forresolving initiator cycles when they have been modified due to a processcalled data combining or collapsing. This third list, referred to as thecombine list, allows combinable bus cycles to also be predictablyresolved.

The initiator cycle list and the target cycle list are passed the samestimulus generated for each bus object in the system, and the cyclelists, in turn, pass that stimulus to each bus cycle state machineobject they contain. The cycle lists provide an organized structure forholding the bus cycles and passing the necessary stimulus to them sothey may transition through their state machines. Each bus cycle statemachine object transitions from state to state in response to certainstimulus signals according to the protocol of the associated bus. Thestate machine of each bus cycle state machine object transitions throughits various states to verify and track the bus transaction according tothe bus protocol and to collect address, data and clock cycleinformation, etc., as desired, to facilitate debug and fault correction.

The bus cycle state machine objects themselves are responsible for mostof the transaction checking verification. The bus cycle state machinestransition in response to bus signals according to the protocol of theassociated bus. After protocol checking and completion of the bustransactions, each bus cycle state machine transitions into a respectiveholding state and remains therein until all data for the transactionassociated with the bus cycle has been accounted for (e.g.,corresponding transactions on target buses have been effectuated). Falsefailures caused by merging of cycle data are no longer created due todata masking employed by the byte granularity data checking methodologyof one embodiment.

Thus, the system monitors and stores various pertinent performanceinformation associated with the bus bridge. Bus objects along with cyclelists and bus cycle state machine objects track resource usage andmonitor bus bridge performance with the help of a statistics-keepingobject.

In one embodiment, the bus bridge is monitored in a device independentmanner, so that false failures can be eliminated and tighterverification of bus bridge operation can be accomplished. A bus bridgemodel object is created with storage space allocated for each of the busbridge's configuration registers. Bus cycle state machine objects pollthis bus bridge model to determine bus bridge state to thereby makedecisions (e.g., remapping, DRAM configuration, etc.) regarding how thecycle should be resolved. Future bus bridge designs can also be testedin a device independent manner by simple modifications to the systemdisclosed.

In still another embodiment, a methodology provides detection of cachecoherency errors in addition to detection of inefficient cache use by acache controller. A cache model object is created with storage (orpointers to dynamically allocated storage) for the address, data andcache status (e.g., MESI states) of each cache line. A cycle list isfurther provided that stores pointers to non-cache bus cycles. Theaddress and data contained by each cache line as well as the coherencystate of the cache line (e.g., MESI state, or other cache coherencyprotocol state) is tracked in the cache model object. Non-cache buscycles, in turn, poll the cache model object to determine their properresolution. In addition, when cache updates occur, the cache model maybe configured to invoke coherency tests upon non-cache bus cycle statemachine objects to verify proper performance.

Thus, the transaction checking system and method may achieve automaticverification of bus bridges without being adversely affected by falsefailures caused by address remapping, byte merging or byte collapsing. Areliable and efficient method of monitoring system buses by simulationthrough object oriented designs is further provided.

In accordance with a further embodiment, bus monitors may be employedalong with the bus bridge model object to determine the values of thebus bridge configuration registers. This allows timing and otherprotocol related functionality of a system bus attached to the busbridge to be verified without restricting the bus monitor to a specificbus bridge design (e.g., without requiring the bus monitors to maintainthe net list names for the various configuration registers identified bythe hardware description language representation of the bus bridge).Additionally, future bus bridge designs can also be tested in a deviceindependent manner.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects and advantages of the invention will become apparent uponreading the following detailed description and upon reference to theaccompanying drawings in which:

FIG. 1A is a block diagram of a computer system including a bus bridge.

FIG. 1B is a command flow diagram of an object oriented bus bridgedesign verification system.

FIG. 2 is a flow chart for state machine based bus cycle completionchecking.

FIG. 3A shows the functional elements in a list based bus cycleresolution checking.

FIG. 3B depicts the pointer operation between the initiator cycle listand the target cycle list as part of bus cycle resolution checking.

FIG. 4A shows a data merging operation performed by a bus bridge.

FIG. 4B shows a method of byte granularity data checking to eliminatemisresolved bus cycles during data merging.

FIG. 5A depicts a byte collapsing operation through a bus bridge.

FIG. 5B introduces a combine list for correctly resolving collapsed datacycles in posted write buffers.

FIG. 5C is an operational flow diagram for the arrangement in FIG. 5B.

FIG. 6 depicts linked objects to statistically monitor performance andresource usage in a bus bridge system.

FIG. 7A shows a cache model object created to check cache coherency.

FIG. 7B is for a verification methodology using the cache model objectin FIG. 7A to check cache coherency during cache and non-cache buscycles.

FIG. 8 shows the computer system of FIG. 1A, but modified to include busmonitors for various system buses. It also depicts a DRAM bus monitoraccessing a bus bridge configuration register to verify the DRAM bustiming.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Itshould be understood, however, that the drawings and detaileddescription thereto are not intended to limit the invention to theparticular form disclosed, but on the contrary, the intention is tocover all modifications, equivalents and alternatives falling within thespirit and scope of the present invention as defined by the appendedclaims.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring now to FIG. 1A, there is shown a general circuit layout of acomputer system 100. A bus bridge 101 is shown connected to varioussystem elements including a CPU 102, a DRAM memory 103, a cache 104 andone or more PCI (Peripheral Component Interconnect) devices 105. AnAdvanced Graphics Port (AGP) device 106 is also shown connected to thebus bridge 101. Various system buses 103A, 104A, 105A and 106A are alsoshown in FIG. 1A.

The bus bridge verification system of the present invention may beexecutable by the computer system 100, or by any other general purposeor specialized computer system. The bus bridge verification system asdescribed below may be used to verify the functionality of a bus bridgedesign, such as bus bridge 101, either upon its initial expression in ahardware description language such as Verilog or following actualhardware implementation.

FIG. 1B is a general command flow diagram of one embodiment of a busbridge verification system. As will be explained in further detailbelow, the bus bridge verification system treats bus cycles asindividual persistent objects. Various additional objects are created toallow for the resolution of created bus cycles, as well as to allow forstatistics keeping and other functionality.

In FIG. 1B, a stimulator object 202 is shown which passes bus stimuluson a clock cycle basis to a plurality of bus objects 204, and also to aninitiator cycle list 214 and to a target cycle list 216. This busstimulus corresponds to bus signal activity occurring on each of thebuses associated with the bus bridge design being verified. Each bus isalso modeled as an individual, persistent object as representedcollectively by the block 204. Two storage objects, 218 and 220, areshown associated with their respective cycle lists 214 and 216 to storecorresponding bus cycle state machine objects created by correspondingbus objects upon detection of the initiation of corresponding buscycles.

The cycle lists, 214 and 216, are configured to pass the bus stimulusfrom the stimulator object 202 to their corresponding storage objects218 and 220 so as to allow for updating of states of corresponding buscycle state machine objects. A bus bridge model object 600 may becreated as an object with storage space allocated for the bus bridge's101 configuration registers. The bus bridge object 600 updates itsregisters using data received from the CPU bus cycle object. Various buscycle state machine objects may poll the bus bridge object 600 forinformation on the bus bridge's 101 currently-set configuration tothereby determine how cycles should be resolved.

A third cycle list, the combine list 402, interacts with the initiatorcycle list 214 to resolve combinable bus cycles created during bytecollapsing operations. Finally, a cache model object 702 is also createdto detect cache coherency errors through interactions with the initiatorcycle list 214 and the target cycle list 216. The cache model object 702may also query the bus bridge object 600 to find configurationinformation pertinent to its operation, such as cache size, write-backor write-through cache, etc. Various detailed aspects of one embodimentof the bus bridge verification system of FIG. 1B are described next withreference to FIGS. 2 through 7B.

Referring now to FIG. 2, a method for checking completion of each of aplurality of bus cycles is shown through a simplified flow chart. Asdepicted therein, initially, bus activity is monitored (step 120) byrespective bus objects to detect the initiation of each bus cycle (step122). Each bus cycle generated by the bus bridge system is described asa state machine object. As each bus cycle begins, a state machine objectcorresponding to that cycle is instantiated during step 123. Forexample, if there is a memory write cycle on the CPU bus 102A, then astate machine object for that cycle will be created. This cycle-basedapproach allows critical monitoring of the bus bridge functionality andavoids instances of false failures arising from address remapping, bytemerging or byte collapsing, as will be described further below. Buscycle state machine objects also provide a means of persistent storagefor various other verification tasks.

The bus cycle state machine object for a particular bus cycle containsstorage for that bus cycle's properties such as clock cycle number,cycle address, cycle type (i.e. read or write), cycle data and thestatus of byte enables. A state machine object updates its state (step124) based on the bus stimulus passed to it on each clock cycle.Referring to FIG. 3A, a stimulator object 202 is created to provide thisbus stimulus to a plurality of cycle lists 208, which in this embodimentincludes an initiator cycle list 214 and a target cycle list 216. Eachcycle list, in turn, passes this stimulus to corresponding bus cyclestate machine objects (206 and 207) stored therein. Additional aspectsregarding this operation will be provided further below.

Referring back to FIG. 2, the final state in the state-machine basedtransition scheme of each bus cycle state machine object is a holdingstate, conveniently referred to as the TARGPEN state illustrated by step128. The bus cycle state machine object remains in the TARGPEN stateuntil the state machine verifies that each byte of its transaction isaccounted for and has been routed to the proper destination (step 130).In other words, a bus cycle state machine object remains in the TARGPENstate until it is resolved by determining that any corresponding cycleson other buses have in fact, been effectuated. When all resolutionchecks are completed in the TARGPEN state 128 the state machine objecttransitions to the FINISH state illustrated by step 132 which signalsthat the bus cycle is complete and that the state machine object can bedestroyed by the corresponding cycle list. Thus, state machine objectsare created and destroyed on a bus cycle basis. This allows verificationthat the bus bridge is asserting signals correctly for each bustransaction. Further details regarding this operation are also providedbelow.

The stimulator object 202 in FIG. 3A reads all stimulus from a set, i.e.a stimulus file 201, of real or simulated buses associated with the busbridge being verified. Cycles or other signals generated by the busbridge being verified cause entries to be provided in the stimulus file201. These stimulus are ultimately detected by a corresponding busobject (i.e., the bus object corresponding to the bus upon which thesignal or cycle is generated). Upon detection of a cycle generated bythe bus bridge, the corresponding bus object creates a bus cycle statemachine object. For most cycles generated by the bus bridge, this buscycle state machine object is provided to the storage object 220associated with the target cycle list 216, since they are normallytarget cycles. Similarly, cycles generated by devices external to thebus bridge are also provided to the stimulus file, and may result insimilar creations of bus cycle state machine objects. Bus cycle statemachine objects that result from externally generated bus cycles aregenerally provided to storage object 218 associated with the initiatorcycle list 214, since they are normally initiator cycles. However, it isnoted that for certain types of cycles, a bus cycle state machine objectmay be provided to both the storage object 218 associated with initiatorcycle list 214 and to the storage object 220 associated with targetcycle list 216. For example, in one embodiment a bus cycle state machineobject created as a result of a CPU writeback cycle is provided to bothstorage object 218 and storage object 220 associated with the initiatorcycle list 214 and target cycle list 216, respectively. In addition, itis noted that certain bus cycle state machine objects created as aresult of cycles generated by the bus bridge are provided to the storageobject 218 associated with initiator cycle list 214 rather than tostorage object 220, such as bus cycle state machine objects created as aresult of cache line replacement read cycles from the cache memory.

It is also noted that the object oriented verification system may beapplied to a bus bridge simulation model and that no physical componentsare needed to be connected. C++ language has been found to bewell-suited for implementation of the verification system. Stimulus file201 contains lines, each line storing a bus stimulus on a per clockbasis. Logic analyzers can also be used to generate the stimulus file201. Bus bridge performance can also be tested through externallysimulated bus signals.

As stated previously, the stimulator object 202 passes the stimulus on aclock cycle basis to a plurality of bus objects 204 and also to aplurality of cycle lists 208. Both the bus objects 204 and the cyclelists 208 are stored in the memory of the computer system 100. Thesystem treats each bus as an individual, persistent object asrepresented by the block 204 in FIG. 3A. Various bus cycles on systembuses are also modeled as objects. Each bus object from the plurality ofbus objects 204 monitors the stimulus passed to it by the stimulatorobject 202 to detect the initiation of a bus cycle. When a bus cycle isinitiated, the bus object corresponding to the bus upon which the cycleoccurs instantiates a bus cycle state machine object--collectivelyrepresented as blocks 206 and 207 in FIG. 3A--for that particular buscycle. That bus object also simultaneously stores that instantiated buscycle state machine object, 206 or 207, in one of the plurality of cyclelists 208 depending upon whether the cycle is an initiator cycle or atarget cycle, as described above.

Thus, in the embodiment of FIG. 3A, each bus object is responsible forplacing the created bus cycle state machine objects into the appropriatecycle list, 214 or 216. The bus objects 204 are also configured to passavailable bus cycle creation data, i.e. the bus cycle's properties, suchas initial cycle address, cycle type, clock cycle number and status ofbyte enables, etc., to individual bus cycle state machine objects upontheir creation. The bus cycle state machine objects, 206 and 207, areconfigured to store their individual bus cycle's properties. The cyclelists 208 provide an organized structure for holding the bus cycle statemachine objects 206 and passing the necessary stimulus to them so theymay transition through their state machines. Thus, for example, when theCPU 102 attempts to write into the DRAM 103, the CPU bus object createsa bus cycle state machine object and stores it in the initiator cyclelist 214; whereas, following generation of a corresponding cycle on thememory bus, the DRAM bus object creates another bus cycle state machineobject and stores it in the target cycle list 216.

In one embodiment, two cycle lists are created as illustrated in FIGS.3A and 3B, block 208. Each cycle list itself is treated as an object.Cycles initiated by bus masters are stored in the initiator cycle list214, whereas cycles sent to bus targets are held by the target list 216.Initially, on each clock cycle, each cycle list polls its bus cyclestate machine objects for their current state. As described earlier inconnection with FIG. 2, each bus cycle state machine object transitionsthrough a sequence of states. Thus, when, during its polling, a cyclelist finds a bus cycle state machine object in its FINISH state, itremoves it from the list because that bus cycle has been successfullycompleted.

After initial polling, each cycle list passes the stimulus from thecurrent clock cycle to each of the bus cycle state machine objectsstored therein. As further depicted in FIG. 3B, bus cycles are stored,through their state machine objects, in an appropriate order. Thus,oldest bus cycles are stored at the cycle list head, and newest buscycles are stored at the cycle list tail. Each line of stimulus in thestimulus file 201 is eventually fed to every bus cycle through theplurality of cycle lists 208, on a clock cycle basis. In one embodiment,the stimulus to the bus cycle state machine objects is passed in theorder list head to list tail, i.e. from the oldest bus cycles to thenewest bus cycles. Passing the stimulus to the bus cycles in this orderfacilitates various tasks, such as insuring that pipelined bus cyclesclaim the correct data from the bus, while keeping all cycles updated intheir states. The bus cycle state machine objects transition their statemachines accordingly, as described earlier with reference to FIG. 2.

Next, the initiator cycle list 214 passes a set of pointers 212 thatpoint to bus cycle state machine objects in the target list 216 to eachinitiator bus cycle state machine object. The pointers 212 are providedto the initiator cycle list 214 from the target cycle list 216. Thepointers 212 are passed to the oldest initiator bus cycle state machineobject first. In one embodiment, a first pointer is passed to the oldestinitiator bus cycle state machine object that points to the newesttarget bus cycle state machine object. This pointer is then successivelypassed to more recently occurring bus cycle state machine objects theinitiator cycle list (i.e., stored in storage object 218). Subsequently,a pointer which points to the second most recent bus cycle state machineobject in the target cycle list 216 is provided first to the oldest buscycle state machine object in the initiator cycle list 214, and so onuntil it is passed to the newest entry in the initiator cycle list 214.This process is repeated until a pointer to the oldest bus cycle statemachine object in the target cycle list 216 is provided to each entry ofthe initiator cycle list 214. As will be described further below, thesepointers are used by each bus cycle state machine object 206 associatedwith the initiator cycle list 214 to pair it with a bus cycle statemachine object 207 associated with the target cycle list 216 todetermine whether the paired cycles resolve, or partially resolve, eachother.

It is noted that in other embodiments, other methodologies are possiblefor allowing initiator bus cycle state machine objects to pair withcorresponding target bus cycle state machine objects for cycleresolution. For example, while in the embodiment described above apointer to the newest bus cycle state machine object in the target cyclelist 216 is provided first to the oldest entry in the initiator cyclelist 214, and successively to the oldest entry in the initiator cyclelist 214, and so on, in other embodiments, the specific order in whichpointers are passed between the cycle lists for cycle pairing may bevaried.

If an initiator bus cycle state machine object has transitioned to itsTARGPEN state 128 (FIG. 2)--(i.e. a state indicating that the busprotocol for the corresponding cycle was properly completed and onlyresolution of target data is pending), or if an initiator cycle statemachine object has transmitted at least one data packet as may occur,for example, during a PCI burst cycle that writes to DRAM, then thatinitiator bus cycle state machine object polls the corresponding targetbus cycle state machine object (i.e., the target bus cycle state machineobject that is pointed to by the current pointer passed to the initiatorbus cycle state machine object) for the target bus cycle state machineobject's properties. These properties include cycle type, cycle address,cycle byte enables, cycle data, and others, as desired. If each of theseproperties matches the predetermined resolution properties for theinitiator cycle state machine object, the data for that initiator cycleis marked as resolved. As described further below, when matching datafor cycles are found, the byte enable bits for that data are cleared.When all the byte enables for a particular cycle have been cleared, thusindicating a complete resolution for the cycle, it enters the FINISHstate and is removed from the cycle list.

Two storage objects, 218 and 220, may be provided which are associatedwith their corresponding cycle lists 214 and 216 (FIG. 3A) to storecorresponding bus cycle state machine objects. At the end of a simulatedtest, the system may still have a number of unresolved bus cycles in theinitiator cycle list 214. Each of these unresolved bus cycle statemachine objects remains in the corresponding storage object tofacilitate debugging. The number and complexity of cycle lists 208 aswell as of storage objects can be varied depending on the testrequirements of the application at hand. The storage objects can eitherbe separately associated with cycle list objects or can be incorporatedas an integral part of each. An error file 222 may be created to storeall pertinent information about unresolved initiator and target cycles.This file can later be accessed by a user for inspection or debuggingpurpose. All these objects are stored in appropriate system memory.

A further implementation of the system addresses the situation of bytemerging. As discussed above, previous methodologies have suffered fromfalse failures due to data merging performed by the bus bridge toenhance performance. FIG. 4A generally depicts a situation where a busbridge 101 merges transactions to adjacent or contiguous memoryaddresses. Four cycles into the bus bridge 101 result in only one cycleout (e.g., to DRAM 103). Previous methodologies assumed that at leastone target bus cycle would exist for each initiated bus cycle. Thisassumption caused verification systems to flag incorrect data forinitiator cycles that did not utilize all bytes on the bus. In thepresent embodiment, a methodology is provided which tracks cycle datawith byte granularity.

As described earlier, byte enables, among other cycle properties, arestored along with each instantiated bus cycle state machine object. Itwas also mentioned before with reference to FIG. 2 that when eachinstantiated cycle object completes its state machine (i.e., the bustransaction has completed), it enters a holding state called the TARGPENstate, represented by block 128 in FIGS. 2 and 4B.

In this TARGPEN state 128 or after at least one data packet has beensent by an initiator cycle, as may occur, for example, during a PCIburst cycle that writes to DRAM, the initiator bus cycle state machineobject compares its cycle properties to those of a paired target buscycle state machine object (which is pointed to by the current pointerit received from the initiator cycle list 214), as already discussedabove with reference to FIGS. 3A and 3B. In the present embodiment,rather than comparing an entire bus width of data, the initiator buscycle state machine object logically masks, e.g. with a logical OR, itsbyte enables with those of the pointed-to target bus cycle state machineobject. Byte enables are only compared when the initiator and targetcycles have the same cycle address (or corresponding bus cycleaddresses, in situations where address translation has occurred withinthe bus bridge (such as, for example, certain AGP operations)) and areof the same type (i.e., read or write), as represented by block 301 inFIG. 4B. Data itself it compared only when the initiator and the targetcycles have one or more common byte enables, as represented by the block302 in FIG. 4B. After this step, each enabled data byte is compared tofind matching data, as shown by the blocks 304, 306, 307 and 308. When adata byte is found matching in the paired bus cycle state machineobjects, the bus cycle state machine object in the initiator cycle list214 (FIG. 3A) toggles (or clears) the byte enable bit associated with itso that the data byte is considered no longer enabled. That initiatorcycle state machine object then instructs the target cycle state machineobject to toggle its corresponding byte enable in the same manner asrepresented by block 310 in FIG. 4B. The clearing of the target cyclebyte enable prevents more than one initiator cycle from using the sametarget cycle data and also allows target cycles to be removed from thetarget cycle list 216 when all their data have been used (i.e., when allbyte enables for the cycle have been cleared). The data corresponding toany other common byte enables in the paired initiator-target cycles aresimilarly compared to selectively clear the byte enables.

The initiator cycle state machine object remains in the TARGPEN stateuntil all of its byte enables are no longer asserted, as depicted byblock 312 in FIG. 4B. When the initiator cycle object exits from itsTARGPEN state and enters a FINISH state 132 (also shown in FIG. 2), itis an indication that all of its data have been accounted for. Thediscussion for this embodiment assumes that the system data bus is32-bit wide, and hence, there can be four data bytes per clock cycle.Further, there can be four byte-enables too, one for each data byte.However, it is clear from this discussion that the system can bemodified to adapt to different bus widths, e.g. 8-bit data bus, 16-bitdata bus, 64-bit data bus etc., and to other specific systemrequirements.

It is noted that after a particular bus cycle state machine object inthe initiator list performs the resolution check as depicted in FIG. 4Bwith a paired bus cycle state machine object in the target list, theinitiator cycle list will cause the pairing of other initiator-targetcycles (i.e., through the passing of pointers as described above) tocontinue the resolution checking process. This process is on-going aslong as there are bus cycle state machine objects in the initiator andtarget lists.

As briefly described before, previous transaction checkers have alsoproduced false failures due to a process called data combining or bytecollapsing used by bus bridges to improve performance. Byte collapsingis distinct from byte merging. When two or more subsequent cycles are tothe same address, the bus bridge 101 may throw away the first cycles andonly propagate the data of the most recent cycle as shown in thesituation depicted by FIG. 5A. The manner in which data combining orbyte collapsing is handled to properly resolve bus cycles in oneembodiment of the system is described next.

Referring to FIG. 5B, in addition to the two cycle lists describedpreviously, i.e. the initiator cycle list 214 and the target cycle list216 as collectively illustrated by the block 208 in FIG. 3A, a thirdcycle list may also be created. The third list is called the combinelist and is shown as block 402 in FIG. 5B. This combine list 402 is afirst-in-first-out (FIFO) list with the number of entries equal to thenumber of entries in the bus bridge's posted write buffer. As with theinitiator and target cycle lists, the combine cycle list is also anobject stored in the appropriate system memory.

As discussed in connection with FIG. 3A, each bus object from aplurality of bus objects 204 monitors the stimulus passed to it by thestimulator object 202 to detect the initiation of a bus cycle. This isalso represented by the block 120 in FIGS. 2 and 5C. As each combinablebus cycle is created, i.e. a cycle wherein bytes are collapsed asdepicted in FIG. 5A, the combinable bus cycle places a pointer to itselfin the combine list 402 during step 408. When a bus cycle state machineobject, in the initiator cycle list 214, for that combinable bus cycletransitions through its states and enters a holding state or if that buscycle state machine object has transmitted at least one data packet, theinitiator cycle list 214 polls the target cycle list 216 for acorresponding matching bus cycle state machine object, as discussedabove with reference to FIG. 3B, during step 410.

If a bus cycle state machine object in the initiator list finds a targetcycle that matches its address, one or more byte enables and targetcycle type, but has different data, then the initiator cycle list 214searches the combine list 402 during step 412 for an initiated bus cyclehaving cycle, address and byte enable attributes identical to those forthe combinable bus cycle, but a later clock cycle number. If such acycle is found and the cycle's data matches the data from the targetcycle, then the initiator cycle list marks that byte enable bit for theoriginal data-mismatched combinable initiator cycle as resolved (i.e.,clears the byte enable bit). In addition, the pointer to the resolvedinitiator bus cycle state machine object is removed from the combinelist 402. The resolution checking of subsequent initiator bus cyclestate machine objects is handled similarly. When the initiator bus cyclestate machine object that corresponds to the last cycle involved in acombined target cycle undergoes its resolution checking process asdescribed above, that object will resolve with the target bus cyclestate machine object of the combined cycle. Additionally, the pointer tothat initiator bus cycle state machine object in the combine list 402 isremoved upon resolution.

When a cycle is combinable, even if the appropriate data and addressresolutions are found from a DRAM cycle (i.e. a target cycle), it may beadvantageous to first check the combine list 402 for any cycle ahead ofthe current combinable cycle that uses the same data and address, as isalso generally shown in FIG. 1B. If such a cycle is found, then theinitiator cycle may be configured not to allow the current combinablecycle to claim resolution from that DRAM cycle. Instead, the newestinitiator cycle in the combine list 402 with that address and data isresolved with the DRAM cycle. Previous cycles with that data and addressresolve themselves without canceling the DRAM cycle.

As each combinable bus cycle completes--i.e. transitions through itsprotocol checking state machine and resolves all its data according tothe methodology described herein, it sends a message to the combinelist. The combine list 402, in turn, removes the pointer to thatcombinable cycle upon receipt of this message during steps 414 and 416.The combinable bus cycle state machine object, having been completelyresolved, thus enters into its FINISH state 132 (FIG. 5C) indicatingcycle completion as discussed earlier in connection with FIG. 2.

The length of the pointer in the combine list can vary depending on theimplementation. In one specific embodiment, the maximum pointer lengthis about four bytes. Further, during a test, there may be occasions whenthe combinable cycle is not fully resolved. In such a situation, theunresolved bus cycle state machine objects remain in their correspondingstorage objects--i.e. unresolved initiator cycles will remain in thestorage object 218, whereas unresolved target cycles will remain in thestorage object 220 (FIGS. 1B and 3A). The concept and functions of thestorage object were discussed previously with reference to FIG. 2A.

The initiator and the target cycle lists can be configured to beresponsive to a user request to download any pertinent information aboutunresolved bus cycles to a file for inspection and debugging. In oneembodiment, an error file 222 (FIG. 3A) stores all pertinent informationabout unresolved initiator and target bus cycles (block 418, FIG. 5C),except for any unresolved target cycle reads, which can be destroyedwithout being reported (e.g., since an unresolved target read cycle doesnot affect coherency). For example, any unresolved DRAM reads can bedestroyed without reporting them in the error file. Further, asystem-wide cycle history file can also be created to store history ofeach bus cycle--whether resolved or not--in the system.

In a further implementation, bus bridge performance and resource usagemay also be monitored. As earlier described in connection with FIGS. 2and 3A, bus objects 204 and bus cycle lists 208 receive a bus stimulusfrom the stimulator object 202 on a clock cycle basis. This stimulus canbe provided through a stimulus file 201. The stimulator object mayfurther be configured to also pass, on a clock cycle basis, the currentcycle count to each object, 204 and 208, in the bus bridge verificationsystem. A statistics keeping object 500 or monitor object is created andstored in the system memory. The statistics keeping object 500 is linkedto the cycle lists 208 and to the bus objects 204 as shown in FIG. 6.

By keeping a stored cycle count for each state transition, each buscycle object can send elapsed time information to statistics keepingobject 500 for performance monitoring. The cycle lists 208 reportresource usage by tracking the type and number of cycles that enter thebus bridge 101 (FIG. 1A). The monitor object 500 then tracks the numberof pending cycles that accumulate within the bus bridge. Messages aresent to the statistics keeping object on each clock cycle indicating thecurrent usage of each tracked resource.

Some uses of the statistics keeping system may include, but are notlimited to, the following: (1) Cycle completion monitoring and testcoverage by bus cycle type can be tracked with the messages from buscycle state machine objects; (2) Request to grant latency monitoring andarbitration scheme verification can be tracked with messages fromdifferent state machines of the bus objects 204; and (3) Usage of thebus bridge's posted write buffer can be monitored with messages from thecycle lists 208.

By monitoring the state of the bus bridge in a device independentmanner, false failures can be eliminated and tighter verification of busbridge operation can be accomplished.

Referring back to FIG. 1B, in this embodiment, a model of the bus bridge600 is created as an object with storage space allocated for a copy ofeach of the bus bridge's configuration registers. This object is alsosuitably stored in the appropriate system memory. As described withreference to FIG. 3A, each bus cycle state machine object also monitorsthe stimulus (from the stimulator object 202) passed to it. As the CPUwrite cycle state machine object monitors the stimulus, it sends buscycles intended for the bus bridge 101 to the bus bridge object 600also. Using the data from these cycles, the model 600 updates itsconfiguration registers accordingly. In this manner, the currentconfiguration state of the bus bridge 101 is always known.

Because the bus bridge model 600 obtains its data directly from the CPUwrite cycle state machine objects, the implementation is not dependenton the actual bus bridge physical implementation. Future bus bridgedesigns can be tested using the same verification system by simplyproviding a new bus bridge model, in software, with the properconfiguration register mapping, allowing direct ports for the rest ofthe verification system objects.

The bus bridge model object 600 provides query functions that returninformation on the bus bridge's state based on function inputparameters. By way of example only, bus cycle objects--i.e. the buscycle state machine objects stored in one or more of the cycle lists 208(FIGS. 1B and 3A)--can directly poll the bus bridge object 600 todetermine if their address is remapped by the bus bridge 101. Thiseffectively eliminates the problems occurring in previous methodologieswhere bus bridge verification systems failed to preserve address countsin situations involving memory remapping. Bus cycle objects can alsopoll the bus bridge model for information on their target resolutionsource. For example, a CPU cycle state machine object can poll the busbridge model 600 to determine whether resolution should come from a DRAMor PCI target cycle. This allows the bus cycle state machines to verifythat the bus bridge 101 is asserting correct signals in each busprotocol. In addition to the bus cycles, various bus objects 204 (FIG.3A), through their state machines, can also poll the bus bridge model600 for pertinent information. For example, an AGP bus object can querythe bus bridge object 600 to determine its operating mode, i.e. a pipedmode or an SBA mode. Finally, a cache model object 702 (described below)can also be configured to query the bus bridge object 600 to findinformation about cache configuration, such as cache size, write-back orwrite through cache, etc.

In a bus bridge verification methodology, it may also be important toverify cache operation. Further, non-cache bus cycles should be able todetermine if their resolving target cycles should come from the cache orDRAM when the bus bridge model 600 (FIG. 1B) indicates that theresolving target cycles should come from the memory subsystem. Inaccordance with one embodiment, a verification methodology for checkingthat cache coherency is preserved by a cache controller is employed.

Referring now to FIGS. 7A and 7B, a model 702 of the cache 104 (FIG. 1A)with storage for the address and data contained in each cache line and aflag indicating the state of the cache line (e.g., MESI state or othercache coherency protocol state) is created. In one embodiment,initially, it may be desirable to store only pointers 704, one for eachcache line, in the cache model and to later dynamically store thecontents of each cache line, including its address and data, as it isbeing allocated by memory. Thus, memory for pointers corresponding tothe cache lines is initially provided. A valid bit may further beprovided to indicate whether a particular pointer is valid. When a linein the cache memory 104 is allocated by the bus master, a correspondinglocation in system memory for tracking by cache model 702 of the line isalso allocated. A value corresponding to this location is then used as apointer 704 to that memory location to allow for updates and statuschecking when transactions associated with or affecting the line occur.This arrangement may result in less storage space requirements. Forexample, if each pointer block 704 is of 4 bytes and if the cache sizeis 4K, then an initial storage space of only 16 kB is required. This isa substantial saving in storage space when compared with storagerequirements for the whole cache--i.e., for example, if each cache linestores 4 bytes of address, 32 bytes of data and 1 byte of flag bits,then for a cache of 4K size, a minimum storage space of 148 KB would berequired.

In another approach, a linked list can be created in the cache modelobject 702 to store each cache line as it is being accessed. Althoughthis method results in less storage space than the pointer-basedapproach, it nonetheless increases search operation time due to itssequential nature of cache line search. In contrast, an array of cachepointers can be effectively utilized to randomly access a cache line.

The cache model object 702 also contains a dynamically allocated cyclelist 703 configured to store pointers to non-cache cycles (i.e., buscycle state machine objects corresponding to busses other than the cachebus) that are initiated in the multi-bus system. Referring to FIG. 7B,an operational scheme to check cache coherency and utilization isdepicted. Each non-cache bus cycle in the initiator cycle list (block214 in FIGS. 1B and 3A) sends a Check Cache message to the cache model702 as represented by block 706 in FIG. 7B. Each cache bus cycle sendsan Update Cache message to the cache model object 702, as shown byblocks 708 and 709 in FIG. 7B. Each cache bus cycle will be stored inthe target cycle list 216 (FIGS. 1B and 3A ), whereas non-cache buscycles may be in the initiator cycle list 214 (FIGS. 1B and 3A)obtaining its resolution from various cycle objects, as discussedpreviously with respect to FIG. 1B.

Update Cache messages serve to update the cache model state. UpdateCache messages also serve as signals to instruct the cache model 702 toperform coherency tests on pending non-cache bus cycles in the cyclelist 703. As each non-cache bus cycle enters its TARGPEN state, i.e., astate indicating that all protocol tests have been successfullycompleted, it sends a Finish Check Cache message to the cache model 702as shown by the block 710 in FIG. 7B. The bus cycle state machine objectrepresentation of each bus cycle in the bus bridge system and variouscycle completion and data resolution mechanisms employing these statemachine objects were described previously. The FINISH state is the laststate in the sequence of state transitions for a bus cycle state machineobject. The Finish Check Cache message indicates that no furthercoherency tests are to be performed on the non-cache bus cycle that sentthe Finish Check Cache message. A more detailed description follows.

As each non-cache bus cycle is created, it sends a Check Cache messagewith a pointer to itself to the cache model (Block 706). The cache model702 determines an initial testing state for the non-cache bus cycledependent upon the type of the bus cycle, the presence of the memoryaddress in the cache and the state of the cache line if the address ispresent in the cache. The pointer to that bus cycle and its initialtesting state, are then stored in the dynamically allocated cycle list703. The pointer may be treated as an object contained by the cacheobject 702. As each new non-cache bus cycle is initiated, a pointerentry is placed on the bottom of the cycle list 703.

Cache cycles send Update Cache messages to the cache model 702 when theyhave completely determined their data. These Update Cache messagesinclude the physical address of the cache line accessed, the data, and aflag indicating if the access was a read or write. The cache model 702,in turn, uses these messages to keep its internal line state up-to-dateand to perform coherency and efficiency checks.

All testing pertaining to each bus cycle is performed on the receipt ofUpdate Cache messages. When an Update Cache message is received, thedynamically allocated list 703 contained in the cache object is searchedfrom the top to bottom, i.e. from the oldest to the newest cycle entry,for an initiated bus cycle whose address matches the address sent by theUpdate Cache message. When such a bus cycle is found, depending on thecycle's assigned initial testing state (block 704, FIG. 7A), a series oftests are performed and the cycle's testing state is updated. In oneembodiment, these tests are performed to determine whether coherency inthe system has been properly maintained. For example, depending upon thestate of a cache line which is accessed as a result of a particularcycle, other cycles such as DRAM cycles may also be invoked in responseto the initiator cycle. The test status information maintained andprovided by the cache model may include information regarding the typeof cycles which should be invoked as a result of the initiator cycle forproper resolution. Certain tests may further be scheduled and conductedto determine whether the state of a cache line has been updatedproperly, whether certain cycles should be aborted, etc., as desired,depending upon the particular cache operation being verified. Failedtests may indicate a failure in the system with respect to coherency.

When each non-cache bus cycle transitions to the FINISH state, it sendsa Finish Check Cache message to the cache object 702 as shown by block710 in FIG. 7B. This message signals that all updates of test state forthe given non-cache cycle should be complete. Upon receipt of the FinishCheck Cache message, the test state for that bus cycle is checked. Ifthe test state for that cycle is not "passed", then an error message isrecorded in the cycle history file described previously. The errormessage can be retrieved by printing or accessing the contents of thecycle history file. A scheme similar to that described with reference toFIG. 3A, i.e. having an error file to store the test data can also beconveniently employed. After the error message has been recorded or thecycle has passed any coherency tests conducted, the pointer to the cyclein the cycle list 703 is removed.

In the above cache-master verification system, each bus cycle in theinitiator cycle list 214 (FIG. 1B) polls the cache verification model702 (FIG. 1B) to determine if its address is currently stored in thecache. If the address is in the cache model 702, then that bus cycle inthe initiator cycle list 214 uses this information in combination withother system data to determine the source of its target resolutioncycles.

When a cache copyback cycle due to non-INV snoops occurs, it is placedin the target list 216 as well as in the initiator cycle list 214 (FIG.1B). The PCI read cycle that generated the snoop, and which itself willbe in the initiator list, will obtain its resolution from the copybackcycle in the target list. The copyback cycle in the initiator list willobtain its resolution from the DRAM cycle. Thus, a partial cache writecan be coherently resolved. A cache read cycle, caused by cache linereplacements, is, however, placed in the initiator cycle list 214. Itwill be resolved by the resulting DRAM write in the target list 216.Thus, a methodology to reliably and efficiently detect cache coherencyerrors in all bus cycles is provided, in addition to detection ofinefficient cache use by a cache controller.

The system described above may thus allow multiple test simulations in amulti-bus environment. The various system objects may interact accordingto the command flow diagram of FIG. 1B and the discussion above. When acomplete resolution, on a cycle-by-cycle basis, is achieved, both theinitiator cycle list and the target cycle list should be empty. Theobjects discussed above e.g. the stimulator object, the bus cycle statemachine objects, the bus objects, the cycle lists, the cache model etc.,may be instantiated by declaring them in the MAIN function supported bythe C++ programming language and stored in an appropriate system memory.

It is noted that the present discussion refers to the assertion ofvarious signals. As used herein, a signal is "asserted" if it conveys avalue indicative of a particular condition. Conversely, a signal is"deasserted" if it conveys a value indicative of a lack of a particularcondition. A signal may be defined to be asserted when it conveys alogical zero value or, conversely, when it conveys a logical one value.

In a situation when bus cycles to addresses are aborted without beingcompleted, the corresponding bus cycle state machine objects may sensethis through the bus stimulus being received from the stimulator objectand may be configured to automatically transition their states, inresponse thereto, to the FINISH state or destroy themselves withoutfurther transitioning their states. Thus, failures due to aborted bustransactions may be eliminated. In addition, the system may also monitorand record bus bridge performance, and may also verify correct behaviorof the bus bridge cache master.

Hence, an efficient and reliable transaction checking system forverifying bus bridges in multi-master bus systems has been disclosed. Bytreating each bus cycle as an individual persistent object, the systemensures that all cycles initiated by bus masters reach theirdestinations without corruption of cycle address or data.

Referring now to FIG. 8, the general circuit layout of a computer system100 in FIG. 1A is shown modified to include a plurality of bus monitors.As described earlier, the bus monitors are modules that monitor thesignals on a given bus and that flag or detect improper operation. Thus,for example, a DRAM memory bus monitor 803 may verify proper RAS and CASpulse width values and DRAM refresh intervals. Bus monitors aretypically constructed in the same hardware design language as the busbridge being simulated. FIG.8 also shows some additional bus monitors,e.g. a CPU bus monitor 802, an AGP bus monitor 806 and a PCI bus monitor805, coupled to their respective system buses.

As previously described, the traditional bus monitor directly accessesthe configuration register values in the bus bridge using the actual netname of the configuration register (e.g., block 801 in FIG.8) of the busbridge design. FIG.8 shows one such access (in phantom) by the DRAM busmonitor 803. Although various timing intervals or other parametersassociated with the operation of bus bridge 101 may be set using busbridge's configuration registers, it would be advantageous to allow thebus monitors, or any other device external to the bus bridge 101, thatrequire knowledge of the internal configuration register values of thebus bridge 101, to access or receive the configuration informationwithout requiring knowledge of the registers'net names employed in thehardware description language representation of the bus bridge. Thiswould allow the bus monitor designs to be portable across various busbridge designs and their revisions.

Thus, in one embodiment, the bus bridge object 600 (FIG.1B) is createdin the memory of the computer system 100 at the beginning of thesimulation, and is accessible by the bus monitors. As previouslydescribed, this bus bridge object or the bus bridge model object 600 hasstorage for all the internal configuration registers contained in thebus bridge design being verified. This storage is initialized to containthe same values as the power-up values for the respective configurationregisters in the real (hardware) bus bridge design. As the simulationprogresses, this bus bridge object 600 receives updates to its registersdirectly from a system bus--typically a CPU bus 102A or a PCI bus105A--used to write to the configuration registers in the bus bridge 101under test. Because the registers in the bus bridge object 600 directlycorrespond with the internal configuration registers in the actual busbridge 101, and because the bus bridge object 600 also obtains its datadirectly from the configuring system bus, the bus bridge object 600'sregisters contain the data identical to that stored in the actual busbridge 101's internal configuration registers.

As configuration writes proceed on a system bus (typically a CPU bus102A or a PCI bus 105A, as already mentioned earlier) its correspondingbus object (block 204, FIG.3A) may model the bus cycles initiated onthat system bus or the bus activity being carried out on that systembus, and may, then, provide the update messages (including the dataidentical to that being written into the bus bridge's configurationregisters) to the bus bridge object 600. The bus bridge object may,then, update its registers accordingly. In another embodiment, the busbridge object 600 itself may directly monitor the system bus, i.e. a CPUor a PCI bus, to receive the bus bridge configuration register datatherefrom.

To determine the value of a configuration register, the bus monitor orany other external monitoring device for the system bus whose timing orfunctionality is being verified may call a function provided by the busbridge object 600, and may supply the desired configuration registeroffset as the argument to that function. Polling the bus bridge object600 in this manner assures that the bus bridge object 600 returns thevalue of the indicated configuration register through its correspondingregisters containing identical storage values. Thus, system bus timingverification becomes independent of the actual bus bridge physicalimplementation. Future bus bridge designs can also be tested using thesame bus monitors or the same external timing and protocol verificationsystem for the existing bus bridge implementation, even though the laterbus bridge designs employ different net names for their internalconfiguration registers.

Numerous variations and modifications will become apparent to thoseskilled in the art once the above disclosure is fully appreciated.Therefore, it is intended that the following claims be interpreted toembrace all such variations and modifications.

What is claimed is:
 1. A method of verifying functionality of a hardwaredescription language representation of a bus bridge in a computersystem, said method comprising:creating a bus bridge object in a memoryin said computer system, wherein said bus bridge object comprises astorage that represents values corresponding to those contained in aplurality of internal configuration registers of said bus bridge;initializing said storage in said bus bridge object with values that arerepresentative of a corresponding plurality of power-up values for saidplurality of internal configuration registers; updating at least one ofsaid values in said storage with data which is identical to that beingwritten into a corresponding one of said plurality of internalconfiguration registers; and polling said bus bridge object to read saidat least one of said values in said storage to verify said functionalityof said bus bridge.
 2. The method as in claim 1, furthercomprising:creating a bus object in said memory corresponding to one ofa plurality of system buses coupled to said bus bridge; and configuringsaid bus object to create bus cycles corresponding to cycles initiatedon said one of said plurality of system buses, thereby tracking a busactivity on said one of said plurality of system buses.
 3. The methodaccording to claim 2, wherein said updating is accomplished byconfiguring said bus bridge object to receive said identical data fromsaid bus object.
 4. The method as in claim 1, wherein said updating isaccomplished by configuring said bus bridge object to directly monitorsaid one of said plurality of system buses to receive said identicaldata therefrom.
 5. The method as recited in claim 1, wherein saidpolling includes:calling a function provided by said bus bridge object;supplying an argument to said function, wherein said argument representsan offset which is identical to that being used to access saidcorresponding one of said plurality of internal configuration registers;and configuring said bus bridge object to return said at least one ofsaid values in said storage in response to said offset.
 6. The methodaccording to claim 5, wherein said polling is performed by an externaldevice simulated in a manner similar to that for said bus bridge, andwherein said external device is configured to monitor said functionalityof said one of said plurality of system buses.
 7. In a computer systemhaving a memory, a CPU and a simulated bus bridge connecting a pluralityof system buses, a method of monitoring a state of said simulated busbridge comprising:creating a configuration state object in said memorycontaining a storage that represents values corresponding to thosecontained in a plurality of internal configuration registers of saidsimulated bus bridge; initializing said storage in said configurationstate object with values that are representative of a correspondingplurality of power-up values for said plurality of internalconfiguration registers; further creating a bus monitoring object insaid memory to detect each bus bridge configuration cycle initiated on aCPU bus, wherein said CPU bus being one of said plurality of systembuses; and configuring said bus monitoring object to update at least oneof said values in said storage with a data from said each bus bridgeconfiguration cycle, thereby maintaining a most current state of saidsimulated bus bridge in said configuration state object.
 8. The methodas in claim 7, wherein said configuring said bus monitoring object toupdate said at least one of said values in said storage is accomplishedby:configuring said bus monitoring object to call an update functionprovided by said configuration state object and to supply in responsethereto said data from said each bus bridge configuration cycle.
 9. Themethod according to claim 7, further comprising:polling saidconfiguration state object to read said at least one of said values insaid storage to obtain said most current state of said simulated busbridge.
 10. The method as in claim 9, wherein said pollingincludes:calling a retrieval function provided by said configurationstate object; supplying an argument to said retrieval function, whereinsaid argument represents an offset which is identical to that being usedto access one of said plurality of internal configuration registers ofsaid simulated bus bridge; and configuring said configuration stateobject to return said at least one of said values in said storage inresponse to said offset.
 11. The method according to claim 10, whereinsaid polling is performed by an external device simulated in a mannersimilar to that for said simulated bus bridge, and wherein said externaldevice dynamically configures itself upon receipt of said at least oneof said values from said storage in said configuration state object. 12.A computer system for verifying functionality of a bus bridgerepresented in a hardware description language, said computer systemcomprising:a bus bridge object stored in a memory in said computersystem, wherein said bus bridge object comprises a storage thatrepresents values corresponding to those contained in a plurality ofinternal configuration registers of said bus bridge, and wherein atleast one of said values is identical to that stored in a correspondingone of said plurality of internal configuration registers; and a pollingobject to poll said bus bridge object to read said at least one of saidvalues to verify said functionality of said bus bridge.
 13. The computersystem according to claim 12, wherein said polling object includes a buswatcher, wherein said bus watcher is simulated in a manner similar tothat for said bus bridge, and wherein said bus watcher is configured toverify a plurality of signals on one of a plurality of system busescoupled to said bus bridge.
 14. The computer system as recited in claim12, wherein one of a plurality of system buses coupled to said busbridge is included in the group consisting of a CPU bus and a PCI bus.15. The computer system as in claim 12, wherein one of a plurality ofsystem buses coupled to said bus bridge is included in the groupconsisting of a CPU bus, a PCI bus, an AGP bus and a DRAM bus.
 16. Thecomputer system as in claim 12, further comprising:a bus objectcorresponding to one of a plurality of system buses coupled to said busbridge, wherein said bus object is stored in said memory and whereinsaid bus object is configured to provide said identical value to saidbus bridge object by tracking a bus activity on said one of saidplurality of system buses.
 17. A computer system for monitoring a stateof a simulated bus bridge in a manner independent of said simulated busbridge's actual physical implementation, said computer systemcomprising:a configuration state object stored in a memory in saidcomputer system, wherein said configuration state object contains astorage that represents values corresponding to those contained in aplurality of internal configuration registers of said simulated busbridge; and a bus monitoring object stored in said memory, wherein saidbus monitoring object updates at least one of said values in saidstorage with a data identical to that stored in a corresponding one ofsaid plurality of internal configuration registers, thereby maintaininga most current state of said simulated bus bridge in said configurationstate object.
 18. The computer system as in claim 17, wherein said busmonitoring object updates said at least one of said values with saiddata captured from each bus bridge configuration cycle initiated on aCPU bus, and wherein said CPU bus being one of a plurality of systembuses coupled to said simulated bus bridge.
 19. The computer system asin claim 17, further comprising:a polling object to poll saidconfiguration state object to read said at least one of said values insaid storage to obtain said most current state of said simulated busbridge.
 20. The computer system as recited in claim 19, wherein saidpolling object includes a hardware description language representationfor a bus monitor, and wherein an operation of said bus monitor isdependent upon said at least one of said values read from said storagein said configuration state object.